Poor-Performing Individuals on a High-Performing Team

Before we get too deep into this particular subject, it’s important to note that not everybody on a high-performing team will always be a “10X programmer.” In fact, on any given high-performing team, you’ll see a wide range of skills. Merely being the slowest developer on the team does not indicate a poor performer, particularly if that individual provides valuable contributions in other ways.

People can contribute in lots of different ways. During his time on the Microsoft patterns & practices team, Ward Cunningham (the inventor of the “wiki”) was praised for his contributions that had nothing to do with code. It turns out that Ward has an uncanny ability. He can sit in a meeting, listening to groups having difficult discussions and saying nothing until the discussion reaches an impasse. When nobody can see a way forward, he’ll ask that one critical question that breaks the logjam and gets everybody moving again. That’s not a skill you pick up as part of a Computer Science degree or boot camp certificate, and it made him invaluable to the teams, regardless of what his code looked like.

Identifying your poor performers means finding those individuals who don’t struggle with just one part of the job, but with all parts of the job. They don’t deliver their code on time, their code is constantly incomplete or incorrect, they don’t communicate their current status well, and so on and so on. The people on your team who consistently underdeliver (and often, if they are seeking to compensate for their shortcomings, overpromise) are your poor performers.

Keep in mind, too, that this quality of “not everybody on your team will be a 10X Programmer” is the norm, not the exception, regardless of how much time, energy, or training you invest into them. Instead, the definition of a high-performing team is one in which the team feels comfortable with each other—they have that quality of psychological safety that I keep mentioning. That doesn’t mean you tolerate shirkers or slackers, but that you recognize that a team is more than just the sum of its parts. Be very reluctant to break up a team that is performing well unless you have a strong reason to believe that removing an individual will benefit the team—and not harm it.

The team knows, sometimes better than you do. A high-performing team knows each other pretty well, including strengths and weaknesses. When in doubt about somebody’s performance, ask other members of the team—they will often spot it quicker than you can. It’s just too hard to hide poor performance from teammates for very long. Asking this can be tricky, however—you don’t want to give your people the impression you’re looking for scapegoats or planning to fire whomever is “last.” Trying to obtain this feedback from the team is what has led to certain management practices like “360 reviews” during performance review time; in general, my personal preference is to rely on the one-on-one. Ask, “Hey, how’s the team? How’s Alfred? How’s Betty? What do you think I can or should be doing for them right now?” and listen carefully to the response. Assuming you get into the habit of asking this on a regular basis—and following up on any suggestions, as best you can—your team will grow to trust that when you’re asking, it’s because you genuinely want to strengthen the team.

Once you’ve identified the poor performers, it’s important to take the next important step, which is to commit yourself to improving them. It may be tempting to cast them aside, figuring that your time is better spent investing in your best players, but doing so yields some negative repercussions:

• They continue to hold the team as a whole back with their poor performance.
• They drain enthusiasm and energy away because the team has to compensate.
• They are often the first ones to complain about anything or everything.

Worst of all, it will send a subtle message to the rest of the team that “sub-mediocrity is acceptable here,” which is almost assuredly not the message you want your team to be receiving.

Realistically speaking, there’s two core options here: Work with them to get better, or release them from the team. For now, the first step is to assume—unless you have concrete evidence to the contrary—that they are just as interested in getting better at their job as you are in them doing so. Then, look to do three things:

• Converse. What’s causing the problems? Are they unclear on what they’re supposed to be doing, or do they perhaps have no idea how they fit into the larger picture? Sometimes the issue is motivation (which we’ll talk about further in the “Motivation” chapter), sometimes the issue is skills, but regardless of the cause, you can’t begin to understand how to help them get better until you begin to understand where the problem is. Gather information: what are they doing or not doing? What expectations are they missing? Reflect: are you part of the problem? Are you assuming they know things they don’t? Are you asking more of them than they can give? And, of course, make room in the conversation for the problem to be of a personal nature—if an employee is quietly trying to support their spouse going through cancer treatment, you can be quite certain their mind isn’t on their work. Find the root cause or causes, as best you can.
• Coach. At some point, you have to tell them that their work isn’t measuring up, but always make sure to pair that with a strong show of support to help them elevate. Much of the chapter on “Feedback” will be applicable here. Make sure you’re giving them feedback liberally laced with coaching. Be specific, erring on the side of repetition. Make sure you place the context around the problem: “This is not the first time we’ve had to discuss the fact that you committed code that failed unit tests, and we’ve talked about this twice before, once last month and once a few months before that.” Be clear in what must change: “This team has a standard, that any code committed to the trunk must pass all unit tests, and we do not call the story ‘done’ until then. I need you to commit to that standard for your own work if you want to remain a member of this team.” Again, review the section on “Feedback” for some hints and tips about how to have this admittedly very uncomfortable conversation. Provide concrete and specific direction on what needs to be done to improve.
• Consider. Don’t make any hasty judgements once you’ve had the conversation. Behavioral change takes time, and if the situation is one that’s not entirely under the team member’s control (the spouse just isn’t responding to the treatments), their performance may understandably suffer. Keep an open line of communication and look to be transparent and supportive—make sure to call out the positive things you notice them doing. Go the extra mile to find those positives, in fact. “Repeats” and “Rewards” (as discussed in the “Feedback” section) are the things to stress here, so that the team member can get that shot of positive feedback and experience that (hopefully) makes it easier for them to do it correctly the next time. As one of my team leads once said, “Every cake needs time to bake before you can tell if the recipe worked.” Look for evidence that the feedback and coaching is taking effect.

Keep in mind that this is all still informal; if you find that this approach isn’t working, it’s time to take the next steps (“When Feedback Isn’t Working”), which can hopefully head off the need for the final step (“Termination”).